TITLE OF THE INVENTION: 

REQUEST REDIRECTION HANDLING IN IMC 



BACKGROUND OF THE INVENTION: 
Field of the Invention: 

[0001] The present invention relates to service request handling in IMC (IP 
Multimedia Core). In particular, the invention relates to redirecting a service request 
for a served user in IMC. 

Description of the Related Art: 

[0002] There are many applications of the Internet that require the creation and 
management of a session, where a session is considered an exchange of data between 
an association of participants. The implementation of these applications is 
complicated by the practices of participants: users may move between endpoints, they 
may be addressable by multiple names, and they may communicate in several 
different media - sometimes simultaneously. Numerous protocols have been authored 
that carry various forms of real-time multimedia session data such as voice, video, or 
text messages. The Session Initiation Protocol (SIP) works in conceit with these 
protocols by enabling Internet endpoints (called user agents) to discover one another 
and to agree on a characterization of a session they would like to share. For locating 
prospective session participants, and for other functions, SIP enables the creation of an 
infrastructure of network hosts (called proxy servers) to which user agents can send 
registrations, invitations to sessions, and other requests. SIP is an agile, general- 
purpose tool for creating, modifying, and terminating sessions that works 
independently of underlying transport protocols and without dependency on the type 
of session that is being established. 

[0003] More details about SIP as defined by the Internet Engineering Task Force are 
described in Request For Comments 3261. As mentioned above, SIP allows the 
establishment, handling and release of end-to-end multimedia sessions. There are 
several additions to the SIP protocol, which e.g. allow event notification based on SIP, 
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which is the basis for a SIP based Presence Service and other services. 

[0004] The 3 GPP IMS (Third Generation Partnership Project IP Multimedia 
Subsystem) utilizes SIP in order to achieve a wide range of functionality within the 
3 GPP (wireless) network. 

[0005] S-CSCFs (Serving Call State Control Functions) in the IMS download filter 
criterions (FCs) from a HSS (Home Subscriber System). FCs are evaluated one-by- 
one, i.e. an incoming request is checked by a terminating S-CSCF based on the public 
user identity in the Request-URI (Universal Resource Identifier) as to whether the first 
or initial FC (highest priority) matches. If it matches, the S-CSCF sends it to the 
related Application Server (AS) that is indicated by the FC and adds a "dialog 
identifier" in the route header that is pointing back to the S-CSCF. 

[0006] When the request is sent back from the AS and received again at the S- 
CSCF,the S-CSCF identifies the request by the dialog identifier and checks for 
matching of the next following FCs of lower priority, and applies the filter criteria on 
the SIP method as received from the previously contacted AS. Depending on the result 
of the previous process, the S-CSCF may contact one or more application server(s). 

[0007] Due to some special services the AS may redirect the request (e.g. Call 
Forwarding). In these cases, it might be undesirable for the AS that the S-CSCF 
performs the subsequent FCs. According to the prior art, such behavior of the S-CSCF 
cannot be affected by the AS. 

[0008] Call forwarding as an example of service request redirection is one of the 
most generally used services in telecommunication systems. Its utilization 
significantly impacts session handling in IP Multimedia Core Subsystem, thus it 
should be accurately defined. 

[0009] The latest version of 3 GPP TS 24.229 Release 5 standard (v.5.3.0) specifies 
terminating procedures at S-CSCF generally without considering the special effects of 
executed services. Request redirection modifies the Request-URI data of the affected 
session, which requires special processing in S-CSCF which cannot be accomplished 
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with the general description of the standard. According to the prior art as described in 
chapter 5.4.3.3 "Request terminated at the served user" of 3GPP TS 24.229, v.5.3.0, in 
a situation of request redirection such as call forwarding, the execution of the rest of 
procedures will conflict with the purpose of call forwarding. 

[0010] According to the general description in point 1 1 of chapter 5.4.3.3 "Request 
terminated at the served user" of 3 GPP TS 24.229, v.5.3.0, the Request-URI is 
overwritten, eliminating the possibility of call forwarding itself. In other words, 
according to the prior art, a Request-URI is built by the S-CSCF with the contents of a 
saved Contact URL (Universal Resource Locator) where the user served by the S- 
CSCF is reachable, which Contact URL is determined from the destination public user 
identity. 

[0011] A specific description of call forwarding is not given so far in IP Multimedia 
Subsystem (IMS), and call forwarding handling in IMS is completely different from 
that in other existing systems. 

SUMMARY OF THE INVENTION: 

[0012] The invention seeks to enable request redirection such as call forwarding in 
IMC. 

[0013] According to one embodiment of the invention, a method of processing a 
service request in an IP multimedia core network includes the steps of receiving a 
service request initiated by a first user, for a second user, forwarding the received 
service request to a unit for processing the service, receiving a processing result from 
the processing unit, and first determining, based on the received processing result, 
whether a service request processing for the second user is to be stopped. 

[0014] According to another embodiment of the invention, a method of processing a 
service in an IP multimedia core network includes the steps of receiving a service 
request initiated by a first user for a second user, from a device serving the second 
user, processing the service, and returning a processing result to the device, based on 
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the processing result the device being configured to determine whether a service 
request processing for the second user is to be stopped. 

[0015] According to another embodiment of the invention, a method of handling a 
service request in an IP multimedia core network includes the steps of receiving a 
service request initiated by a first user, for a second user, in a device serving the 
second user, forwarding the received service request to a unit for processing the 
service, receiving the forwarded service request in the processing unit, processing the 
service in the processing unit, returning a processing result to the device, based on the 
processing result the device being configured whether a service request processing for 
the second user is to be stopped, receiving the processing result by the device from the 
processing unit, and determining, based on the received processing result, whether the 
service request processing for the second user is to be stopped. 

[0016] According to another embodiment of the invention, a device for processing a 
service request in an IP multimedia core network includes means for receiving a 
service request initiated by a first user, for a second user, means for forwarding the 
received service request to a unit for processing the service, means for receiving a 
processing result from the processing unit, and means for determining, based on the 
received processing result, whether the service request processing for the second user 
is to be stopped. 

[0017] According to another embodiment of the invention, a unit for processing a 
service in an IP multimedia core network includes means for receiving a service 
request initiated by a first user, for a second user, from a device serving the second 
user, means for processing the service, and means for returning a processing result to 
the device, based on the processing result the device being configured to determine 
whether a service request processing for the second user is to be stopped. 

[0018] According to the invention, the tasks to be executed by a terminating S- 
CSCF in case of call forwarding are defined. In case of call forwarding, the 
terminating S-CSCF does not evaluate further filters but handles the call forwarding. 
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Moreover, tasks which may be executed by an application server in case of call 
forwarding are defined. 

BRIEF DESCRIPTION OF THE DRAWINGS: 

[0019] For a better understanding of the present invention and as to how the same 
may be carried into effect, reference will be made by way of example only to the 
accompanying drawings in which: 

[0020] Fig. 1A shows a flow diagram illustrating a method of service request 
processing according to the invention; 

[0021] Fig. IB shows a flow diagram illustrating a method of service processing 
according to the invention; 

[0022] Fig. 2 shows a schematic block diagram illustrating a serving device and a 
processing unit in an IP multimedia core network according to the invention; 

[0023] Fig. 3 shows a signaling diagram illustrating service request handling 
according to an embodiment of the invention; 

[0024] Fig. 4 shows a signaling diagram illustrating an example of call forwarding 
handling in S-CSCF according to an embodiment of the invention; and 

[0025] Fig. 5 shows a signaling diagram illustrating another example of call 
forwarding handling in S-CSCF according to an embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS: 
[0026] Fig. 1A illustrates a method of processing a service request in an IP 
multimedia core network. In step SI 1, a service request for a user is received by a 
device serving the user. For example, this service request has been initiated by a first 
user towards a second user. After having received the service request, in step S 12 it is 
forwarded to a unit for processing the service. Then, in step SI 6, a processing result is 
received from the processing unit, and on the basis of the received processing result in 
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step S 17 it is determined whether service request processing for the second user is to 
be stopped. 

[0027] Fig. IB shows a method of processing the service according to the service 
request forwarded to the processing unit. In step S13 a service request initiated by the 
first user towards the second user is received from the device serving the second user. 
In step S 14 the service is processed, and in step SI 5, a processing result is returned to 
the device, on the basis of which it can be determined in the device (in step S17 in Fig. 
1 A) whether service request processing for the second user is to be stopped. 

[0028] Fig. 2 shows an IP multimedia core network (IMC network) 29 arranged to 
perform steps Sll to S17 shown in Figs. 1A and IB. In particular, the IMC network 
29 includes a device 20 serving a user for processing a service request for the served 
user and a processing unit 28 for processing a service corresponding to the service 
request. 

[0029] The serving device 20 includes a first receiving block 22 for receiving a 
service request for the served user, a forwarding block 21 for forwarding the received 
service request to the processing unit 28 for processing the service, a second receiving 
block 23 for receiving a processing result from the processing unit 28, and a 
determining block 24 for determining, on the basis of the received processing result, 
whether service request processing for the served user is to be stopped. 

[0030] The processing unit 28 includes a receiving block 25 for receiving the service 
request from the serving device 20, a processing block 26 for processing the service, 
and a returning block 27 for returning a processing result to the serving device 20, on 
the basis of which it can be determined in the device 20 whether service request 
processing for the second user is to be stopped. 

[0031] According to an embodiment of the invention, the processing unit 28 may 
include in the processing result an indication for stopping service request processing 
for the served (second) user. Accordingly, the serving device 20 is arranged to check 
whether the processing result received from the processing unit 28 includes the 
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indication for stopping service request processing for the second user, and in case the 
indication is present, to stop service request processing for the second user. The 
serving device 20 may also be arranged to check whether the indication is valid. 

[0032] Moreover, before stopping service request processing for the second user, the 
serving device 20 may perform charging processing. 

[0033] According to another embodiment of the invention, the received service 
request initiated by the first user may include a destination identifier of the second 
user, and upon service processing, the processing unit 28 may determine that the 
service request is to be forwarded to a third user, replace the destination identifier of 
the second user by a destination identifier of the third user, and return the processing 
result with the destination identifier of the third user to the serving device 20. The 
serving device 20 may compare the destination identifiers of the service request 
forwarded to the processing unit 28 and the processing result received from the 
processing unit 28, and in case it is detected that the compared identifiers are different 
from each other, service request processing for the second user is stopped. In addition 
the serving device 20 may determine, on the basis of the received processing result, 
whether the service request is to be forwarded to a third user, and may forward the 
service request to the third user on the basis of the destination identifier included in 
the processing result. 

[0034] The service request of the first user received by the serving device 20 for the 
second user may include an originating identifier of the first user, and the processing 
unit 28 may include an originating identifier of the second user in the processing result 
when it determines during processing the service that the service request is to be 
redirected from the second user to a third user. Then, in the forwarding procedure, the 
serving device 20 may detect that the originating identifier included in the processing 
result is the originating identifier of the second user, and may forward the service 
request on the basis of the originating identifier included in the processing result. 
However, in case the originating identifier included in the processing result is not the 
originating identifier of the second user, the serving device 20 may include the 
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originating identifier of the second user in the service request to be forwarded. 
Alternatively, in the forwarding procedure, the serving device 20 may always use the 
originating identifier included in the processing result. 

[0035] According to an embodiment of the invention, the originating identifier of 
the first user is replaced by the originating identifier of the second user. Alternatively, 
the originating identifier of the second user is added to the originating identifier of the 
first user. 

[0036] In the following, an embodiment of the invention will be described with 
reference to Figs. 3 to 5. 

[0037] Fig. 3 shows a signaling diagram in which a user A (first user) sends an 
initial service request towards a user B (second user). The service request is received 
by a device in the IMC serving user B (serving device), e.g. an S-CSCF (Serving Call 
State Control Function). The S-CSCF forwards the initial service request to a 
corresponding application server AS (processing unit) for the user B at which the 
service request is processed. After that, the AS returns a processing result to the S- 
CSCF. In so far, the process corresponds to 3 GPP TS 24.229 version 5.3.0 release 5, 
chapter 5.4.3.3 "Requests terminated at the served user". 

[0038] According to the invention, in processing the terminating services of a served 
subscriber or user in S-CSCF, after each service execution a check should be 
performed to determine whether the service included a process because of which the 
S-CSCF should not perform the subsequent filter criteria. For example, in case of 
service redirection such as call forwarding further terminating services of the called 
party should not be executed, i.e., the check for matching of the next following filter 

criteria of lower priority should be stopped. 

) 

[0039] As shown in Fig. 3, the S-CSCF of the user B detects from the processing 
result received from the AS that the terminating processing for the user B is to be 
stopped. Before stopping the terminating processing, the S-CSCF may perform 
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charging related functions as described in points 5 to 7 of chapter 6.4.3.3 "Request 
terminated at the served user" of 3GPP TS 24.229 v.5.3.0 release 5. 

[0040] Further to the detection that the terminating processing is to be stopped, 
according to the invention it may be detected by the S-CSCF that the service request 
has to be forwarded to another user C. After such detection, the S-CSCF may handle 
this request redirection by performing charging related tasks as mentioned above and 
switching to originating mode, and finally forwarding the initial service request 
towards the user C as shown in Fig. 3. 

[0041] Fig. 4 shows an example of the embodiment of Fig. 3. According to Fig. 4, 
the initial request sent towards the B S-CSCF includes an R-URI (Request-Universal 
Resource Identifier) (destination identifier) of user B. The B S-CSCF forwards the 
request to the AS of user B. In processing the service, the B AS may detect a 
redirection of the service request to user C, for example. Since in this case the B S- 
CSCF should not perform subsequent filter criteria, the B AS may set an indication 
that the B S-CSCF should not evaluate further filter criteria. 

[0042] The AS may set this indication as part of e.g. the Request-URI of the request 
that is sent back to the S-CSCF. This may be a tag in the Request-URI, e.g.: 

sip:Georg.Mayer@miesbach.de;FC==off 
wherein M sip:Georg.Mayer@miesbach.de" is the R-URI of user C. 

[0043] This indication may also be set in another way (e.g. extra header, parameter 
of another header, etc.) 

[0044] The S-CSCF should then check if the indication is allowed to be set by the 
AS from which it received the request back. If it is allowed to set it, the S-CSCF 
should then stop evaluating the subsequent FCs and handle the request redirection 
immediately (or at least immediately after having performed charging operations as 
mentioned above). In other words, when the B S-CSCF detects the tag n FC=off 1 in the 
processing result returned from the B AS, it stops the terminating processing for the 
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user B and switches to the originating role e.g. for handling a call forwarding towards 
the Request-URI indicated in the returned processing result. 

[0045] Fig. 5 shows a further example of the embodiment of Fig. 3. According to 
Fig. 5, the initial request sent towards the B S-CSCF includes an R-URI (Request- 
Universal Resource Identifier) (destination identifier) of user B and a P-A-ID (P- 
Asserted Identity) header (originating identifier) of user A. 

[0046] The B S-CSCF forwards the request to the AS of user B. The result of 
processing the service may be a redirection of the service request to user C. In order to 
detect request redirection, the Request-URI sent to the AS and the Request-URI 
received from the AS are always compared by the S-CSCF. As shown in Fig. 5, the R- 
URI has changed from B to C, so that the S-CSCF detects that the executed request 
included a request redirection, such as call forwarding. 

[0047] In call forwarding case the P- Asserted ID header should be modified so that 
the user C is enabled to notice that the request or call from user A is coming through 
user B. For example, if user C has a call barring for user A and user A calls user B 
who has call forwarding to user C, then from user B's point of view the forwarding 
will fail. According to the invention, the modification of the P- Asserted ID header 
may be done either by the AS implementing the call forwarding service or the 
terminating S-CSCF that detects call forwarding (in case the AS did not modify the 
header). According to Fig. 5, the B AS has already modified the P-A-ID from A to B. 
The modification is either the replacement of the P-Asserted ID header with the 
served user's IMPU (IP Multimedia Public User Identity) (it can be another IMPU of 
the served user as well) as shown in Fig. 5, or the insertion of the served user's IMPU 
(again, it can be another IMPU of the served user as well) at the beginning of the 
original P-Asserted ID header, i.e. 'P-A-ID=B,A\ As shown in Fig. 5, the call is then 
forwarded with P-A-ID - B. 

[0048] After the detection of call forwarding in the B S-CSCF, the B S-CSCF may 
carry out the tasks related to charging as it is described in points 5, 6, and 7 of chapter 
5.4.3.3 "Request terminated at the served user" of 3GPP TS 24.229 v.5.3.0 release 5. 
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If user B has set call forwarding, then user B should pay for the forwarded part of the 
call from B to C. 

[0049] Upon completing charging related functionality the terminating S-CSCF 
changes the role from terminating S-CSCF to originating S-CSCF, and starts to 
operate as it is described in chapter 5.4.3.2 "Request initiated by the served user" of 
3 GPP TS 24.229 v.5.3.0 release 5, wherein the served user in this originating S-CSCF 
is the forwarding IMPU stored in P- Asserted ID header, i.e. user B. In other words, 
the B S-CSCF switches to originating role and forwards the initial service request 
towards user C in accordance with 3GPP TS 24.229 version 5.3.0 release 5, chapter 
5.4.3.2 "Request initiated by the served user". 

[0050] The B S-CSCF should ensure that all the restrictions/settings defined for the 
calls originated by B are fulfilled. Therefore, according to the present invention, the 
originating services of the user B are executed. Not executing originating services in 
case of call forwarding, for example, would enable subscribers to call barred numbers 
by setting call forwarding to such numbers and calling themselves. 

[0051] It is to be noted that the charging tasks shown as block 5 in Fig. 5 may also 
be performed in the embodiment shown in Fig. 4 after the detection that the 
terminating processing for B is to be stopped and before actually stopping the 
terminating processing for B. Moreover, the P-A-ID modification can also be applied 
to the embodiment shown in Fig. 4. 

[0052] Moreover, it is to be noted that the above examples can be combined in 
different manners. For example: 

With respect to R-URI change: 

a. B AS just changes the R-URI, and there is no special indication in the processing 
result. 

b. B AS indicates the change of R-URI in the processing result. 
For changing P-A-ID there are two places for options: 
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The place of change: 

0. No change (this is a possible option too, although this way C will not know that B is 
involved). 

1. Done inB AS. 

2. Done (at some point) in B S-CSCF after the redirection has been detected. 
The way of change: 

X. Replace A with B. 
Y. Replace A with B,A. 

Then, possible combinations are 0, IX, 1 Y, 2X, and 2Y. 

[0053] Taking into account also the R-URI change, possible combinations are aO, 
bO, alX, MX, al Y, bl Y, a2X, b2X, a2Y, and b2Y. 

/ [0054] It is to be understood that the above description is illustrative of the invention 
and is not to be construed as limiting the invention. Various modifications and 
applications may occur to those skilled in the art without departing from the true spirit 
and scope of the invention as defined by the appended claims. 
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